Conventional multipoint video teleconferencing via a network utilizes a central server, which typically requires a central server for all parties to send their data, which is then rebroadcast to all parties from the central server. Generally, each party or remote site connects to the central server (i.e., central hub, point, or bridge) via the network, and each data transfer hop flows from a source remote site, to the central server, and then from the central server to each destination remote site, which requires at least two hops over the network: one hop from the source site to the central server and another hop from the central server to each destination site. In some instances, when working with user responses via a video teleconference, the two hop delay over the network may often cause user interaction to be unnatural and awkward.
Conventional multipoint video teleconferencing requires all data to be transmitted to a single point (i.e., the central hub) for assembly and retransmission. In a satellite network, this often requires the data to be transmitted to the satellite, then to the central server, then to the satellite again, and then to the destination site. Accordingly, this process incurs a two-hop latency problem, which significant degrades the response time on interactive applications, such as video and voice (i.e., audio).
As a result, there currently exists a need to improve network based multipoint video teleconferencing to overcome the deficiencies of conventional techniques.